To expand the number of size of subnets, bridging devices are often used. Any time two or more layer two devices (e.g., bridging devices) are bridging a subnet across the same link (e.g., in a redundant configuration), there exists the possibility of introducing a bridging loop. For example, consider the case where two bridging devices are both performing address resolution protocol (ARP) requests for an unknown address. Upon receipt of the request on one interface, the default behavior will be to repeat this request as a broadcast to the other side. However, the other bridging device will then receive the request and repeat it back on the original segment, causing a bridge loop that must be intercepted.
Another problem with utilizing a plurality of bridging devices to bridge a subnet is handling ARP responses. Whenever a second device bridges the same subnet as a bridge that is repeating ARP traffic, it will receive the ARP response on both sides of the subnet. Furthermore, the response will typically be received first on the correct side, and then on the repeated side. Learning the location of the device by receiving these ARP requests will usually result in storing the incorrect state. Currently, there is no standardized way of resolving this problem.
The bridge loop has been prevented in the past by detecting the other devices and not doing proxy ARP for these devices, and by maintaining state about pending requests to prevent re-broadcast of identical ARP requests.
Incorrect bridge learning from repeated ARP traffic has been prevented in the past by using proxy ARP (substituting the bridge's MAC address for the original device's MAC), and then learning which devices are proxy devices, and ignoring proxy responses when other responses are also being received. Some devices use a proprietary protocol to communicate state about the bridging table to solve this problem. Both of these previous solutions have disadvantages, however, ranging from connectivity outage when a device is moved, to extra network traffic. In addition, these solutions preclude a bridging device from doing repeat (non-proxy) traffic in a redundant configuration.
Accordingly, a need exists for a method and device for detection of bridge loops in the case of ARP. A need also exists for a method and device that accomplishes the above need and for determining which of two proxy devices to use to reach a device in the shortest number of hops. A need also exists for a method and device that accomplishes the above needs and for determining whether or not to respond to an ARP request. A need also exists for a method and device that accomplishes the above needs and for filtering out repeat traffic without requiring additional messaging.